There is a need to locate and dispatch server objects as fast as possible in response to requests. Requests can originate in-process from a client subsystem of an object request broker (“ORB”) or out-of-process, from a client which is separate from the server. A typical request contains the request ID server address (e.g., an Internet protocol address), an operation to be invoked (e.g., a software method), and an object key which is used to identify a specific object. The object key is marshaled into a byte array for transfer along with the rest of the request, for example, to a network socket at the ORB server. Multiple requests (or “threads”) are ordinarily pending at any one time for handling by an ORB server.
Once the request is at the server, the byte array is unmarshaled back into a textual form (e.g., “U.S.A./California/San Mateo.123”). A hierarchy of portable object adapters (“POA”) located within the ORB server are ascribed textual names and are accessed by traversing the hierarchy using the information in the object key. Thus, as shown in FIG. 1 for Bank X, a hierarchy of POAs are contained within their server, in which the POA, “U.S.A.” is accessed followed by the POA “San Mateo” (again, as opposed to some other locality within the parent state “California”) until the specified object “123” is located. Thus, traversal of the POAs starts at a root and continues down the tree defined by the object key. The server can only now invoke the requested method on the specified object. Object “123” can be one bank account, whereas objects “456” and “789” can be different accounts. The method to be performed can, by way of illustration, be account balance inquiries, deposits, withdrawals, transfers, and the like, or other methods appropriate to the type of objects in a given ORB server.
Once the method has been invoked on the specified object, the server initiates a reply method which places the value, if any, resulting from the method along with the IP address of the client (if appropriate), and a request ID that permits the reply to be matched to the request.
The unmarshaling and the POA traversal consume time which results in a lower system performance. For a transaction oriented application built upon an ORB, the number of transactions per second is greatly limited by this traversal to the identified object.
What is needed in the art is a methodology for improving ORB performance. What is further needed is software constructs to implement such a method. The present invention satisfies these and other needs.